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PROVISION OF A MULTIMEDIA BROADCAST/ MULTICAST SERVICE (MBMS) FOR A USER 
EQUIPMENT MOVING AMONG CELLS IN A CELLULAR MOBILE COMMUNICATION SYSTEM 

This invention relates to Multimedia Broadcast/Multicast Services (MBMS) in mobile 
communication systems. More particularly, the invention relates to methods for 
5 ensuring MBMS service provision for a mobile device which is moving between cells in 
a cellular mobile communication system. 

In the third generation telecommunication systems, higher bit-rates are offered as well 
as better possibilities for transmitting variable bit rate traffic. For instance, services 
10 utilizing different quality requirements are possible to multiplex. Such possibilities open 
up for new types of sen/ices. One of these services that will be included in the 3GPP 
(3rd Generation Partnership Project) standard is a Multimedia Broadcast/Multicast 
Service (MBMS). 

15 The intention with MBMS is that different users can subscribe to broadcasting and/or 
multicasting of multimedia information of different kinds. An information provider thus 
transmits the same multimedia information to a number of users. Since multimedia 
information typically requires high transfer capabilities, a simultaneous 
broadcasting/multicasting of such information will occupy a number of times as large 

20 transfer capabilities compared with a single transmission. It is therefore advantageous 
for the network to determine whether particular MBMS data must be transmitted 
continuously, or whether it can be transmitted discontinuously. Further, it is 
advantageous for the network to determine whether particular MBMS data must be 
transmitted to specific users (point-to-point transmission), or whether it can more 

25 efficiently be transmitted by point-to-multipoint transmission. 

The network must be able to make these determinations on a continuous basis, 
depending on the current locations of the users which wish to receive the particular 
MBMS data. 

30 

SUMMARY 

According to the present invention, there are provided procedures for the establishment 
of MBMS services in different cells of a cellular telecommunications network. In 
35 particular, there are provided procedures for maintaining transmission of MBMS data to 
a particular user equipment, even as it moves from one cell to another, when the 
service Is provided In different ways in different cells. 
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In addition, there is provided suitable hardware for performing the procedures 
according to aspects of the invention. The hardware may be in the form of user 
equipment, which is adapted to receive IVIBMS data, or radio network controllers, which 
5 are adapted to receive MBMS data and transmit it to receiving equipment, or core 

network equipment, which is adapted to establish the required connections to transmit 
data to the receiving equipment via the radio network controllers. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The Invention, together with further objects and advantages thereof, may best be 
understood by making reference to the following description taken together with the 
accompanying drawings, in which: 

FIG. 1 is a schematic Illustration of an embodiment of a mobile communication 
system; 

FIG. 2 Is a block scheme of an embodiment of a mobile communication system; 
FIG. 3 Is an embodiment of a protocol model for a UTRAN in a mobile 
communication system; 

FIG. 4 shows the signalling flow In a first procedure earned out in a network 
according to the invention; 

FIG. 5 shows the signalling flow in a second procedure carried out in a network 
according to the invention; 

FIG. 6 shows the signalling flow In a third procedure carried out in a network 
according to the invention; 

FIG. 7 shows the signalling flow in a fourth procedure carried out in a network 
according to the invention; 

FIG. 8 shows the signalling flow In a fifth procedure earned out In a network 
according to the invention; 

FIG. 9 shows the signalling flow In a sixth procedure carried out in a networi< 
according to the invention. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

jhe present invention comes into use mainly in the third generation mobile 
35 communication systems. A typical example of such a mobile communication system 1 
is Illustrated in Fig. 1. A core network 10 Is provided with connections 5 to external 
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networks (not shown), such as e.g. PSTN (Public Switched Telephone Network). ISDN 
(Integrated Services Digital Network) or Internet. The core network 10 is also 
connected 17 to a UTRAN (UMTS Radio Access Network) 20 comprising a number of 
Radio Network Controllers (RNCs) 22A, 22B, 22C over an lu interface 16. In the 
5 illustrated embodiment, the three RNCs 22A, 22B, 22C are interconnected 15 by an lur 
interface 14. 

In the illustrated RNCs 22A, 22B are controlling two base stations 30A-D each by 
connections 25 over an lub interface 24. (In the present embodiment, the RNC 22C 

10 does not directly control any base stations.) The base stations 30A-D are also 

commonly known as "Node Bs" In the 3GPP specifications. Each base station 30A-D 
operates the radio access within a certain geographical area, or cell, 40A-D. User 
equipment 50A-D moves within the coverage of the cells 40A-D and can communicate 
by radio communication 35 via a Uu interface 34 with at least one of the base stations 

1 5 30A-D. The base stations 30A-D thereby comprise means for communication over the 
radio interface Uu 34 according to prior art within this field. Similarly, the user 
equipments 50A-D comprises means for communication over the radio interface Uu 34 
according to prior art: within this field. The details of these devices and methods are not 
essential for the understanding of the present invention and are furthemiore easily 

20 available in standard literature. The User Equipment UE 50A-D typically comprises 
mobile equipment 51, e.g. a mobile phone or a portable computer, and a user SIM 
(Subscriber Identity Module) card 52. 

The internal communication of a mobile communication system 1 according to Fig. 1 is 
25 easier to overview if the system 1 is illustrated in an altemative manner, as in Fig. 2. 
Here the four fundamental subnetworks - the external networks 2, the core network 10, 
the UTRAN 20 and the UE 50. The extemal networi<s 2 may comprise more traditional 
telephony networi<s based on circuit switched technology 3, such as PLMN (Public 
Land Mobile Network), PSTN or ISDN. The external networks 2 may also comprise 
30 packet based communication networks 4, such as the Intemet. 

The core networi< 10 comprises In this embodiment a GMSC (Gateway Mobile 
Switching Centre) 18, which is a switch at the point where all circuit switched 
connections to and from external networks pass. A MSCA/LR (Mobile Services 
35 Switching CentreA/isitor Location Register) 1 1 , connected to the GMSC 18, is a switch 
and database that serves the UE for circuit switched services when the UE is within the 
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range of a RNC 22 of the UTRAN 20 connected to the core network 10. The MSG 
function is used to switch the circuit switched calls. The VLR function holds track e.g. of 
the visiting user's service profile. The MSCA/LR 1 1 and the GMSC 18 are also 
connected to a HLR (Home Location Register) 13, which is a database located in the 
5 user's home system comprising a master copy of the user's service profile. The service 
profile comprises e.g. infomriation about allowed services, supplementary service 
information and will in the case of MBMS also comprise information about such 
sen/ices. The HLR 13 stores the UE 50 location on the level of MSCA/LR and/or 
SGSN. 

10 

The core network 10 also comprises nodes connected to GPRS (General Packet Radio 
Service). A GGSN (Gateway GPRS Support Node) 19 is a switch at the point where all 
data packet traffic to and from external networks pass. The GGSN 19 is connected to a 
SGSN (Serving GPRS Support Node) 12. The functionality of the SGSN 12 is similar 
15 as for the MSCA/LR 11, but for packet switched services. The SGSN 12 and the GGSN 
19 are also connected to the HLR 13. There might also be an optional Interface 
between the MSC/VLR 1 1 and the SGSN 12. 

The core network 10 communicates via the lu interface 17 with the UTRAN 20. In this 
20 embodiment, the UTRAN 20 is illustrated to comprise two RNCs 22, interconnected by 
the lur interface 14. Each RNC 22 has as in Fig. 1 control of Node Bs 30, which in turn 
communicate with the UE 50. A RNC 22 and associated Node Bs constitute together a 
Radio Networic Subsystem (RNS) 26. 

25 The RNC 22 is the network element responsible for the control of the radio resources 
of UTRAN 20. It interfaces the CN 10 and also tenninates a Radio Resource Control 
(RRC) protocol that defines the messages and procedures between the mobile 50 and 
the UTRAN 20. Within the UTRAN 20, a RNC 22 can take up different roles, e.g. as a 
Serving RNC (SRNC), a Drift RNC (DRNC) or a Controlling RNC (CRNC). 

30 

A CRNC is always directly associated with one or more Node Bs 30. The CRNC is 
responsible for the load and congestion control of its own cells and executes the 
admission control and code allocation for new radio links to be established in those 
cells. The CRNC thus terminates the lub Interface 24 towards the Node B 30. 
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In the 3GPP standard, a UE can use resources for the UE-to-UTRAN connection from 
more than one RNC, The RNCs available in the UTRAN will then play different roles 
with respect to that particular UE. A SRNC for a particular mobile is a RNC that 
terminates both the lu link for the transport of user data and the corresponding 
5 signalling to and from the core network related to radio access. The SRNC terminates 
further radio resource control signalling between the UE and the UTRAN. The SRNC 
may be a CRNC, but not necessarily. However, a specific UE has one and only one 
SRNC. 

1 0 A DRNC is any other RNC that controls cells used by the UE. A DRNC of a UE is 
consequently always different from the SRNC of that specific UE. The DRNC routes 
data between the lub and lur interfaces. A certain UE may therefore have zero, one or 
more DRNCs. 

15 One physical RNC normally contains all the CRNC, SRNC and DRNC functionalities. 
Furthermore, a SRNC associated with a certain UE may simultaneously be a DRNC for 
another UE. 

A general protocol model for UTRAN terrestrial interi'aces is illustrated in Fig. 3. The 
20 protocol structure 100 consists of two main layers, a radio network layer 101 and a 
transport network layer 103. All UTRAN-specific Issues are visible only in the radio 
network layer. The protocol structure 100 Is also divided into vertical planes, a control 
plane 105 and a user plane 107. The control plane 105 and the user plane 107 are 
therefore present in both layers 101, 103. Furthermore, a transport network control 
25 plane 106 is additionally available in the transport network layer 103. 

The control plane 105 is used for all UMTS control signalling. It includes an application 
protocol 1 1 1 and a signalling bearer 1 13 for transporting application protocol 
messages. The application protocol 1 1 1 is typically used for setting up bearers to the 
30 UE, e.g. radio access bearer in the lu interface and radio links in the lur and lub 
interfaces. 

The user plane 107 is instead responsible for the transmission of all actual information 
to the user, e.g. in the form of coded voice or general data packets. The user plane 107 
35 includes data streams 115 and data bearers 1 17 for the data streams 115. Each data 
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Stream 1 15 is characterized by at least one protocol specified for that particular 
interface. 

The transport network control plane 106 is used for ail control signalling within the 
5 transport layer and acts therefore between the control plane 105 and the user plane 
107. 

The MBMS is a service offered by a content provider to subscribers of such a service 
that comprises synchronized broadcasting and/or multicasting of multimedia 
1 0 information to a number of users. 

The present invention does not relate to data transfer In the core network as such. 
Therefore the provision of the MBMS data from a content provider to a suitable SGSN 
is performed according to any suitable prior-art solution and is not described more in 
15 detail. In the following description, it is therefore assumed that at least one SGSN has 
the requested MBMS data from the particular broadcast/multicast service center 
available in one way or the other, e.g. via an GGSN as an entry point. The role of the 
SGSN is in this context to perform user individual network control functions and to 
provide MBMS transmissions to the radio access network. 

20 

It Is also assumed herein that, since the handling of multi-cast services and broadcast 
services is Identical for the UTRAN. there is no need to differentiate between them. 

The transmission of an MBMS service in the UTRAN on the Uu interface to the UE can 
25 be effected as: point-to-point (PTP) transmission; point-to-multlpoint (PTM) Continuous 
transmission; point-to-multipoint (PTM) Discontinuous transmission; or>Arith either PTP 
or PTM Discontinuous transmission available. Each of these possibilities is described 
In more detail below. 

30 In the case of point-to-point (PTP) transmission, those UEs that want to receive a 
certain MBMS service will receive the infomnation via point-to-point radio links. 

In the Non-Access Stratum (NAS) domain, that is, transparent to the UTRAN. the UE 
indicates that it wants to receive a certain MBMS service. As a result, the CN 
35 establishes a nomnal RAB towards this specific UE which will carry the MBMS data. 
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Since only point-to-point transmission is used in tliis alternative there is no need to 
have the UTRAN aware that there are transmissions ongoing related to a 
broadcast/multicast service. 

5 In the case of PTM Continuous transmission, Continuous PTM transmission of a 
certain MBMS service is configured in certain service areas (cells). 

The PTM transmission is in this alternative is not dependent on e.g. the user load in the 
cell concerned. 

10 

This alternative is most suitable for MBMS sen^ice provisioning in areas where the 
likelihood of a significant number of interested UEs is high. 

In the case of PTM Discontinuous transmission, a certain MBMS service always uses 
15 PTM transmission. However, the PTM transmission will be turned on only if there is at 
least one UE in a cell interested in receiving the MBMS service. If no UE in a cell is 
interested in a certain MBMS service, the relevant PTM transmission will be switched 
off. 

20 This avoids some of the disadvantages of PTM Continuous transmission, because 
there is no transmission when no UE is receiving, but it does not provide the same 
flexibility as the alternative described below. 

In the case of the situation where PTP and PTM Discontinuous transmission are both 
25 available, a certain MBMS sen/ice will be provided based on PTP transmission if the 
number of UE's that wants to receive this MBMS service in a specific cell [#(MBMSx 
interested UE's)] is low. When, but only when, the number of receiving UE's in a 
certain cell exceeds a certain threshold TRptp<^p™, the UTRAN will switch to PTM 
transmission in that cell. 

30 

This behaviour is reflected in the following expressions: 



If #(MBMSx interested UE's) = 0 

If TRpTP«p™ > #(MBMSx interested UE's) >0 

If #(MBMSx interested UE's) >TRptp<^ptm 



=> No MBMS transmission 
=> PTP MBMS transmission 
=> PTM MBMS transmission 



35 
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FTP transmission will always provide the most radio resource efficient transmission if 
only one UE in a cell is Interested in a certain MBMS service. Using a sensible value 
for TR PTP^>PTM, this alternative will provide the most radio-resource efficient solution - 
compared to the other alternatives listed here, TR ptp<^ptm is assumed to have a 
5 typical value between 2 and 5. 

Given the MBMS transmission alternatives, discussed above, on the Uu interface, it is 
also necessary to consider the necessary MBMS Transmission Modes on the lu 
interface from the Core Network to the UTRAN, and whether the Core Network needs 
10 to be aware of and/or support the selected transmission alternative. 

In the preferred embodiments of the invention, point-to-multipoint transmission is 
realised in the Radio Access Network by using the FACH transport channel. The 
FACH transport channel is a common channel for which (power) control and 
1 5 scheduling are completely handled by the CRNC. 

In the case of continuous PTM transmission, the UTRAN does not need to be aware of 
how many UEs are interested in a specific MBMS service in the cell. Stated differently: 
the UTRAN does not need to track users which want to receive a certain MBMS. That 
20 is, it does not need be aware of the cell in which such users are located. As a result, 
no involvement of SRNC's is required. 

This is different for the cases where discontinuous transmission is possible. In these 
cases, the UTRAN does need to be aware of the number of UEs that want to receive a 
25 certain MBMS service in a cell, in order to switch transmissions on and off, or to switch 
between PTP and PTM transmission (in the case where both are available). In these 
alternatives, the UTRAN needs to be able to track UEs receiving a certain MBMS 
service. 



30 In preferred embodiments of the present invention, where it is necessary for the 
UTRAN to be aware of the number of users that want to receive a specific MBMS 
service, the counting by the UTRAN is based on: 

UE-specific RAB's established towards these UEs, and 
Mobility monitoring based on RRC connection related signalling. 
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This approach is assumed to minimise the required Impact on the user equipment and 
the UTRAN, while still resulting In acceptable performance. 

Since it is the SRNC that handles the signalling on the lu interface for a specific UE, 
5 and it is the SRNC that handles the RRC connection towards a specific UE, the CN 
therefore needs to involve SRNCs In the MBMS handling when discontinuous 
transmission is available. CRNCs may also be involved in this case since the PTM 
transmission is handled by the CRNC. 

10 Summarising the above, the CN needs to distinguish between two modes, which can 
be referred to as MBMS Fixed transmission mode, and MBMS Variable transmission 
mode. 

In MBMS Fixed transmission mode: 
15 - CN only needs to inform CRNCs of the cells corresponding to a certain service 
area about a certain MBMS service; 

CN does not enable the UTRAN to track MBMS users; 

UTRAN is only able to use point-to-multipoint (PTM) Continuous transmission. 

20 In MBMS Variable transmission mode: 

CN needs to inform the SRNC of a UE that wants to receive a specific MBMS 
service; 

CN enables UTRAN to track MBMS users in RRC Connected Mode; 
UTRAN is able to use discontinuous transmission (either point-to-multipoint, or 
25 with point-to-multipoint and point-to-point alternatives both available) for users in RRC 
Connected Mode; 

UTRAN is unable to track MBMS users in RRC Idle Mode, but It is also able to 
use point-to-multipoint (PTM) Continuous transmission for such users. 

30 Thus, if the UTRAN detects certain areas In which there are always a sufficient number 
of UEs to justify PTM transmission, it should be possible for the UTRAN to use point-to- 
multipoint (PTM) Continuous transmission in those cells. UEs should be able to detect 
if an RRC connection is required in a cell for receiving a specific MBMS service, and 
take the corresponding action. 
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Thus, although as mentioned above, it is assumed that the UTRAN does not need to 
differentiate between broadcast and multicast services, in prefen-ed embodiments of 
the Invention an MBMS broadcast service will only use the Fixed transmission mode so 
that it becomes available without requiring any RRC connection. An MBMS multicast 
5 service could use either the Fixed transmission mode or the Variable transmission 
mode. 

Figure 4 shows the signalling In a case in which the CN requests the UTRAN to provide 
a transmission of a certain MBMS service In the fixed transmission mode, In a 
10 particular area. 



In step 401. a PDP context Is activated between the UE and the CN and, in step 402, 
the UE sends an Internet Group Management Protocol (IGMP) Join Request to the CN. 
These steps are transparent for the UTRAN. They are only required in the case of an 
1 5 MBMS multicast service, not in the case of an MBMS broadcast service. 

In step 403, when there Is data to be transmitted In the requested MBMS service, the 
CN will initiate the MBMS ACTIVATION REQUEST. There could be a significant period 
without any data transmission, and so this step could occur quite some time after 

20 specific UE's have sent an IGMP Join Request. In this illustrated embodiment of the 
Invention, the MBMS ACTIVATION REQUEST Identifies the MBMS service by the 
combination of the Access Point Name (APN) (that Is. the DNS name of the Intended 
Access Point, which may for example be a GGSN, Including Identlflera for the operator 
and network) and the IP multicast address. The relatively long (30-40 bytes) APN is 

25 required since different networks (or different broadcast centres) may use the same IP 
MC address. In other embodiments of the invention, a shorter Identity may be used. 

In step 404. the RNC will immediately initiate the bearer establishment procedure if it 
was not already receiving the data. If lu-flex is not configured, the RNC will only be 
30 aware of one SGSN. If lu-flex is configured, the RNC may know multiple SGSNs. In 
this case the RNC can send the message to any SGSN it knows. It is therefore 
assumed that any SGSN the RNC knows is able to provide the data for any requested 
MBMS service. 



35 



In step 405. the CN sends the MBMS bearer establish response to the CRNC. 
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In step 406, the CRNC begins transmission of point-to-multipoint transmission on the 
Uu interface to the interested UEs. It is assumed that the UE on its own will be able to 
detect the MBMS service transmission in the relevent cells. If the UE has joined the 
MBMS service and has received the correct keys, it will be able to receive the MBMS 
5 service without any further CN or UTRAN support. 

Thus, whenever there is a PTM transmission for a certain MBMS service ongoing in a 
cell, a UE needs to be able to detect this transmission and receive it, whether it is in 
RRC Idle mode or RRC Connected Mode. Moreover, whenever there is a PTM 
10 transmission for a certain MBMS service ongoing in a cell, a UE needs to be able to 
determine if it is required to establish an\RRC connection in order to ensure the PTM 
transmission, or if no RRC connection is\equired. 

If there is no ongoing PTM transmission for a certain MBMS service, it is not required 
15 for the UE to be able to distinguish between a cell in which the MBMS service 
information can be provided and a cell in which the MBMS service X cannot be 
provided. 

At least three different steps can be discemed in the MBMS related information that 
20 needs to be sent over the Uu. Firstly, the CRNC must broadcast configuration 

information regarding ongoing PTM MBMS data transmission. Secondly, the CRNC 
needs to page UEs in the event of actual data transfer. Thirdly, the CRNC needs to 
perform the actual MBMS data transfer. 

25 A new MBMS System Information Block (SIB) should preferably be defined for the 
purpose of configuration. The MBMS SIB would contain for each MBMS service 
broadcast in the cell the following information: 
IP MC address 

Physical channel (S-CCPCH) related information 
30 - Transport channel (FACH) related information 
Logical channel related information 

multicast Radio Network Temporary Identifier (MC-RNTI), which temporarily 
identifies the group of UEs 

35 The MBMS SIB therefore configures the MBMS Radio Bearer carrying the MBMS data 
in the cell, when using PTM data transmission. In general, this information should not 
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then be changed too frequently, since SIB updating requires sending notifications to all 
UEs. 

In a UE-power-efficient solution. UEs should not be mandated to have to monitor the 
5 relevant FACH channel continuously if there is no ongoing transmission of the relevant 
MBMS service. This can be achieved by means of a fixed timing scheme, or by using 
paging. 

Thus, in the case of fixed timing, every MBMS service could only be allowed to start 
10 transmission at certain frame positions. A UE receiving this MBMS service would only 
have to start listening at these instances. If nothing is received in the relevant radio 
frame, the UE can go to sleep again until the next possible scheduling occasion. 

Alternatively, paging can be used to inform the UE when to listen to the FACH channel. 
15 The MBMS paging should be specific to a specific MBMS service. The cunrent UE- 
specific paging can be made suitable for MBMS paging either by allocation of a RNTI 
per MBMS service, or by using the 12 remaining bits on the Paging Indicator channel 
(RICH). 

20 The actual data transfer in step 406 is assumed to be transported over the FACH 
channel and uses a special MC-RNTI. One possible logical channel which could be 
used is a Common Traffic channel (CTCH). 

Finally, In Figure 4, step 407 shows the CRNC sending an MBMS activation response 
25 to the CN as acknowledgement. 

Figure 5 shows an example of the de-activation scenario for the fixed transmission 
case. 

30 In step 501 , the CN sends a MBMS deactivation request to the CRNC, identifying the 
specific MBMS service by means of the MC address. The CRNC responds by stopping 
PTM transmission on the Uu interface, in step 502, and by sending an MBMS bearer 
release request to the CN in step 503. The CN replies In step 504 with an MBMS 
bearer release response, and the process concludes in step 505, with the CRNC 

35 sending a deactivation response to the CN as acknowledgement. 
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Figure 6 shows the signalling flow in a case in which the CN requests the UTRAN to 
provide a transmission of a certain MBMS service in the variable transmission mode. 

In step 601 , a PDP context is activated between the UE and the CN and. in step 602, 
5 the UE sends an IGMP Join Request to the CN. The IGMP Join Request has no 

confirmation at IGMP level, but will be confirmed with other MAS signalling (transparent 
to UTRAN). 

Incidentally, it is assumed that the CN will configure the service provision that a 
10 particular MBMS service may or may not be available in a particular area. This may 
cause difficulties when the UE performs the IGMP join in an area where the service is 
not provided, or when the UE performed the join in an area where the service is 
provided, but then passes into an area where the service is not provided. Taking the 
UE location into account would make the handling of the IGMP join very complicated. 
15 Therefore, in the presently preferred embodiment of the invention, the handling of the 
IGMP join is decoupled from the question of whether the UE is in fact in an area where 
it can receive the service. As a result, it is theoretically possible that the UE might 
perform a successful IGMP join, but still not receive the service data, and the CN 
should configure the service areas such that this is an unlikely case. 

20 

In step 603, when there is data to be transmitted in the requested MBMS service, the 
CN will send the MBMS ACTIVATION REQUEST to the relevant SRNC. There could 
be a significant period without any data transmission, and so this step could occur quite 
some time after specific UE's have sent an IGMP Join Request. In this illustrated 

25 embodiment of the invention, the MBMS ACTIVATION REQUEST identifies the MBMS 
service by the combination of the APN (that is, the DNS name including identifiers for 
the operator and network) and the IP multicast address. The relatively long (30-40 
bytes) APN is required since different networks (or different broadcast centres) may 
use the same IP MC address. In other embodiments of the invention, a shorter identity 

30 may be used. 

Before establishing the user plane over lu, the SRNC first checks if the CRNC wants to 
provide the MBMS-service based on a PTM transmission. Thus, in step 604, the 
SRNC sends an MBMS attach request to the CRNC, identifying the requesting UE and 
35 the multicast address. In step 605, the CRNC sends a MBMS attach response to the 
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SRNC, and, in this example, the CRNC Indicates that it intends to provide PTP 
transmission of this MBMS service. 

Assuming that the SRNC does not already provide the requested I\/1B1\/IS service to any 
5 UE, it triggers a bearer establishment procedure in step 606, by sending a MBMS 
bearer establishment request to the CN. In step 607, the CN then sends the MBMS 
bearer establish response to the SRNC. 

The SRNC may need to reconfigure the existing radio links in order to be able to 
10 handle the additional transmission and, if so, sends a radio link reconfiguration request 
to the CRNC in step 608, to which the CRNC responds in step 609. 

In step 610, the SRNC begins PTP transmission of the MBMS service data on the Uu 
interface. Then, after the transmission of the relevant MBMS service has started, in 
15 step 61 1 , the UTRAN confirms user specific activation to the CN. 

Figure 7 shows the signalling flow In an altemative scenario in which the CN requests 
the UTRAN to provide a transmission of a certain MBMS service in the variable 
transmission mode. 

20 

In step 701 , a PDP context is activated between the UE and the CN and, in step 702, 
the UE sends an IGMP Join Request to the CN. The IGMP Join Request has no 
confirmation at IGMP level, but will be confirmed with other NAS signalling (transparent 
to UTRAN). 

25 

In step 703, when there is data to be transmitted in the requested MBMS service, the 
CN will send the MBMS ACTIVATION REQUEST to the relevant SRNC. There could 
be a significant period without any data transmission, and so this step could occur quite 
some time after specific UE's have sent an IGMP Join Request. In this illustrated 

30 embodiment of the invention, the MBMS ACTIVATION REQUEST identifies the MBMS 
service by the combination of the APN (that is, the DNS name including identifiers for 
the operator and network) and the IP multicast address. The relatively long (30-40 
bytes) APN is required since different networks (or different broadcast centres) may 
use the same IP MC address, in other embodiments of the invention, a shorter identity 

35 may be used. 
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Before establishing the user plane over lu, the SRNC first checks if the CRNC wants to 
provide the MBMS-service based on a PTM transmission. Thus, in step 704, the 
SRNC sends an MBMS attach request to the CRNC, identifying the requesting UE and 
the multicast address. 

6 

In this illustrated example, the CRNC indicates that it intends to provide PTM 
transmission of this particular MBMS service, but is not yet providing the MBMS service 
to any UE (it will be appreciated that this is a relatively unlikely combination). 
Therefore, in step 705, the CRNC triggers a bearer establishment procedure. In step 
10 706, the CN then sends the MBMS bearer establish response to the CRNC. 



In step 707, the SRNC begins PTM transmission of the MBMS service data on the Uu 
Interface. Then, after the transmission of the relevant MBMS service has started, the 
UTRAN confirms user specific activation to the CN, by means of a MBMS attach 
15 response from the CRNC to the SRNC in step 708 and a MBMS user activation 
response in step 709. 

As discussed above, there will be areas (cells) in which a UE is required to have an 
RRC connection when receiving MBMS information (discontinuous PTP or PTM 
20 transmission) and areas where such an RRC connection is not required (continuous 
PTM transmission). The question then arises as to how to handle situations in the 
case of movement of a UE, receiving a MBMS service, between two cells, where this 
requirement is different for the two cells. The preferred embodiment of the present 
invention provides the following capabilities. 

25 

When the UE passes from a first cell with PTM transmission, where an RRC 
Connection is not required, to a second cell with PTM transmission, where an RRC 
Connection is again not required, all that is necessary Is for the UE to read the new 
broadcast information and tune to the correct FACH. No UTRAN invblvement is 
30 required. 

When the UE passes from a first cell with PTM transmission, where an RRC 
Connection is required, to a second cell with PTM transmission, where an RRC 
Connection is again required, the UE is required to perform the conventional procedure 
35 for changing cells when in RRC Connected mode, and then read the MBMS broadcast 
information. 
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When the UE passes from a first cell with PTM transmission, where an RRC 
Connection is required, to a second cell with PTM transmission, where an RRC 
Connection is not required, the necessary action depends on the reason why the UE 
5 had its the RRC connection established. If the RRC connection was established for 
another reason in addition to receiving the MBMS service, e.g. for a speech call, the 
RRC connection will remain as normal. 

When the UE only has the RRC connection for enabling the reception of the MBMS 
10 service, no Radio Bearer (RB) will have been established towards the UE, although a 
Radio Access Bearer (RAB) exists. In this case, only the Signalling Radio Bearers 
(SRBs), used for RRC and NAS signalling, but not for data transfer, will be configured. 
Figure 8 shows a signalling flow in this case. 

15 In step 801 , the UE originally has a signalling connection (as well as the RRC 
connection), and sends a SIGNALLING CONNECTION RELEASE INDICATION 
message to the SRNC. This message Is already defined in the UMTS standard, for 
use in rare error cases (e.g. MSC restart with loss of UE context), but is also preferably 
used in this case. Preferably, the message includes an Infomiatlon Element (IE) 

20 indicating the cause of the message. 

In step 802, since the UE is moving to RRC Idle mode, the SRNC role no longer needs 
to be fulfilled for this UE. Therefore the lu connection for this UE can be removed, and 
the SRNC sends a RRC connection release request to the UE. in step 803, the UE 
25 responds by sending a RRC connection release complete message. 

The UE will be able to configure a MBMS Radio Bearer from the MBMS SIB being 
broadcast In the second cell. Then, In step 804, while the CRNC continues sending the 
PTM transmission of the MBMS data on the Uu interface to the UE, the SRNC sends 
30 an lu release request to the CN, specifying the cause that the UE has moved into an 
area where an RRC connection Is no longer required. As a result of this step, an 
SGSN might get data from a GGSN, but it does not have to deliver it to any RNC. 

In step 805, the CN sends the lu release command to the SRNC, which responds in 
35 step 806 with an lu release complete message. In step 807, If the SRNC no longer 
needs the corresponding bearer, a bearer release will be requested. (Of course, the 
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CRNC is still receiving the MBMS data for the relevant service.) The procedure 
completes In step 808, when the CN sends the MBMS bearer release response to the 
SRNG, 

5 When the UE passes from a first cell with PTM transmission, where an RRC 

Connection is not required, to a second cell with PTM transmission, where an RRC 
Connection is required, the UE receiving the MBMS service in RRC Idle mode now 
detects that an RRC connection is required. 

10 Figure 9 shows the signalling required to establish the RRC Connection. It will be 
noted that Figure 9 assumes that PTM transmission is already ongoing in the cell to 
which the UE Is moving. 

In step 901 , the UE will Initiate RRC Connection establishment. The message 
15 preferably includes a new cause value. In step 902, the SRNC responds with a RRC 
Connection setup message and, in step 903, the UE responds with a RRC Connection 
setup complete message. 

Then, In step 904, the UE contacts the CN to trigger the UE-specific MBMS activation. 

20 In one embodiment of the invention, a normal Routing Area Update (RAU) is used for 
this purpose. In another embodiment of the invention, a service request is sent. In one 
embodiment, the NAS message indicates for each MBMS service whether or not an 
MBMS ACTIVATION REQ Is needed. In an altemative embodiment, the CN performs 
an activation for all MBMS services ongoing towards this UE. In the remainder of 

25 Figure 9, it is assumed that at least one activation is required. 

In step 905, the required lu signalling connection is required. Then, in step 906, an 
MBMS activation request is sent. In step 908, the SRNC sends the MBMS user 
activation response to the CN. Meanwhile, in step 907, the SRNC has been continuing 
30 the PTM transmission, which can now be received by the UE in the new cell. 

The UE may pass from a first cell with PTP transmission, where an RRC Connection is 
required, to a second cell with PTM transmission, where an RRC Connection is not 
required. 
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In different embodiments of the invention, different entities may detect that the RRC 
connection is no longer required. Thus, in one embodiment of the invention, the SRNC 
detects that the RRC connection is no longer required. This is achieved by the SRNC 
by doing the attach to the DRNC, and the DRNC then telling the SRNC that it is already 
5 providing the service with a PTM to the UE and that no RRC connection is required. In 
that case, the SRNC can then inform the UE that it should start to receive the MBMS 
service via the PTM transmission and release the RTF RAB and possibly the RRC 
connection. (The SRNC can instead decide to maintain the RRC Connection, even 
though there is no immediate requirement for it.) This option Is simpler from the point 
10 of view of the UE, but requires that the SRNC is aware of the ongoing MBMS services. 

In another embodiment of the invention, the UE detects that the RRC connection is no 
longer required. By monitoring the MBMS SIB, the UE can then detect that the RRC 
connection is no longer required for this service, and triggers the release of the RRC 

15 connection. This is simpler for the UTRAN, but requires that the UE be able to monitor 
the MBMS SIB even in a "CELL_DCH" state. In the "CELL^DCH" state, the UTRAN 
(specifically the SRNC) detemnines which cell the UE should use. The UE has a 
dedicated channel, but this requires that the UE should also be able to read the 
common channel (that is. the BCH or FACH) on which the MBMS SIB is transmitted, in 

20 parallel with the dedicated channel, and therefore requires more complexity in the UE. 

The question of detecting the status also arises in the case of a UE with a speech call 
moving between cells where the MBMS service is transmitted with FTM transmission. 
In some embodiments of the invention, the UE detects the FTM transmission; in other 
25 embodiments, the SRNC informs the UE about it. 

The UE may pass from a first cell with FTF transmission, where an RRC Connection is 
required, to a second cell with FTM transmission, where an RRC Connection is 
required. Conversely, the UE may pass from a first cell with FTM transmission, where 
30 an RRC Connection is required, to a second cell with FTF transmission, where an RRC 
Connection is required. In either case, the change is handled by means of RRC 
Reconfiguration messages under control of UTRAN. 

The UE may pass from a first cell with FTM transmission, where an RRC Connection is 
35 not required, to a second cell with FTF transmission, where an RRC Connection is 
required. This is handled in the same way as described above, when the UE passes 
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from a first cell with PTM transmission, where an RRC Connection is not required, to a 
second cell with PTM transmission, where an RRC Connection is required, except that 
a dedicated channel is established. 

5 Finally, the UE may pass from a first cell with FTP transmission, where an RRC 
Connection is required, to a second cell with PTP transmission, where an RRC 
Connection is again required. According to the present invention, this is handled in the 
UTRAN, in the same way as a conventional UE mobility procedure in CELL_DCH 
state, except that the DRNC additionally informs the SRNC that it does not want to 
10 provide the MBMS service on a PTM basis. 

Procedures exist by which the CN can inform the UTRAN about the start or stopping of 
transmission for all UEs receiving this MBMS service. This signalling will exist between 
BMSC, GGSN and SGSN. According to preferred embodiments of the present 
15 invention, the signalling triggers a release of the user plane resource while still keeping 
the MBMS contexts in the network, so that an easy later continuation of the service is 
possible. 

In some embodiments of a network In accordance with the present invention, only 
20 CRNC's are provided with MBMS functionality. They provide the MBMS service with a 
fixed PTM transmission (the MBMS Fixed transmission mode described above). In 
addition, MBMS services with an expected low number of interested UEs can be 
handled with PTP transmission. This has the advantage that it has limited impact on 
the UTRAN, and specifically means that the SRNC does not need to be MBMS aware. 
25 PTM Is available for MBMS services with expected high number of receiving UEs, while 
PTP is available for MBMS services with expected low number of receiving UEs, and 
there is support for reception in RRC Idle mode in PTM areas. However, each MBMS 
service is provided either always on a PTP basis or always on a PTM basis, requiring 
the CN to estimate the expected average number of receiving UEs. 

30 

In other embodiments of a network in accordance with the present invention, all 
UTRAN RNC's are upgraded to become MBMS aware, and MBMS services are 
provided based on PTM, but the transmission can be turned on or off based on the 
number of receiving UEs. This has the advantage that there is no unnecessary PTM 
35 transmission if no interested UE is present, while there is support for reception in RRC 
idle mode in PTM areas with continuous PTM transmission. IHowever, all UTRAN 
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RNCs (SRNCs and CRNCs) need to become MBMS aware, and only PTM is 
supported. 



In other embodiments of a network in accordance with the present invention, all 
5 UTRAN RNCs are upgraded to become MBMS aware, and MBMS services can be 
provided based on PTP or on continuous PTM transmission in configured areas. This 
has the advantage that an MBMS service can be provided either by PTP or by PTM in 
one cell, based on the expected number of UEs in that cell, and that there is support for 
reception in RRC Idle mode In PTM areas. However, all UTRAN RNCs (SRNCs and 
10 CRNCs) need to become MBMS aware, and there is no switching between PTP and 
PTM in one cell. 



However, in the most preferred embodiments a network in accordance with the present 
invention, all UTRAN RNCs are upgraded to become MBMS aware, and all of the 
15 transmission alternatives discussed above are possible. This has the advantage that it 
provides the best solution from the point of view of radio efficiency, and supports 
reception in RRC Idle mode in PTM areas with continuous PTM transmission. 
However, it is the most complex solution. 

20 Based on the above, it should be clear that, when the CN wants to provide a certain 
MBMS service, it has to configure the UTRAN with information regarding the service 
areas in which this MBMS service should be provided with a fixed transmission mode, 
and in which service areas the MBMS service can be provided with a variable 
transmission mode. This configuration phase of the UTRAN for a specific MBMS 

25 service will be UE independent. 

It will be understood by those skilled in the art that various modifications and changes 
may be made to the present invention without departure from the scope thereof, which 
is defined by the appended claims. 



30 



